Why tiCrypt Uses MFA — But Never Trusts It
Security isn't just about having the right tools. It's about how you use them.
Multi-Factor Authentication has become a cornerstone of modern cybersecurity. Whether you're chasing CMMC compliance, meeting NIST standards, or simply trying to keep bad actors out, MFA is table stakes. Duo, Shibboleth, NetID — these tools are everywhere, and for good reason: they work.
So why does tiCrypt refuse to trust them?
The Problem With "Trusting" MFA
Most platforms treat MFA as the final word on identity. Pass the second factor, get access. Simple.
The trouble is that this creates a single point of failure hiding behind a false sense of security. If an attacker finds a way to spoof or hijack a session on the backend — after MFA has already done its job — the authentication is effectively bypassed. The lock on the front door doesn't matter if someone can walk in through the wall.
tiCrypt is built on a different philosophy: Zero Trust, implemented completely. That means we don't grant implicit confidence to any single system — not even MFA.
Decoupling Authentication From the Platform
Instead of weaving MFA directly into our backend, tiCrypt treats identity providers as independent "proof-providers." They vouch for a user. They do not get keys to the kingdom.
Here's how it works in practice:
- A small, minimal-footprint web page protected by Shibboleth and Duo handles the initial login. Upon successful authentication, a PHP script uses a private signing key to create a digitally signed message containing the user's identity and a timestamp.
- The corresponding public key is shared with tiCrypt via configuration — nothing more. The two systems never talk to each other directly.
- tiCrypt's backend informs the frontend of the MFA factors it needs satisfied before a session can begin, then uses that public key to cryptographically verify the signed message.
The result: even if the authentication server were compromised, an attacker would gain nothing useful. There is no direct path to the encrypted data on tiCrypt.
Split Credentials: Your Key, Your Control
Because external MFA factors are used, tiCrypt adds another layer of protection: split credentials.
Every user's private key is encrypted with AES-256. Decrypting it requires three components working together:
- The encrypted private key (stored in the user's key file)
- An initialization vector (IV) — securely and randomly generated
- A cryptographic salt — also securely and randomly generated
Without MFA, the IV and Salt live in the user's key file. With MFA enabled, they are stored on the server and protected by the MFA, effectively splitting the secret across two independent systems.
This has a powerful implication: even if a user accidentally loses their private key file, it is useless without the server-side IV and Salt. An attacker would be left trying to brute-force AES-256 directly — a task so computationally expensive it makes cracking an RSA-2048 key look affordable by comparison.
Split credentials also mean that when a user changes their password, all older copies of their key are instantly invalidated. The server regenerates the IV and Salt with every password change, so stale or stolen key files simply stop working.
MFA Is a Challenge, Not the Authentication
This is where tiCrypt's approach diverges most sharply from conventional thinking. In most systems, passing MFA is the authentication — it's the gate that grants access. In tiCrypt, MFA is simply one of several challenges that must be satisfied before a session is established. It is never the thing doing the actual authenticating.
The real authentication in tiCrypt is always performed by the user's private key. When a session is negotiated, the server issues a randomly generated 32-byte challenge. The user's client must return a digitally signed response using their private key — a signature the server can verify against the corresponding public key. No private key, no session. Full stop.
MFA fits into this flow as an additional proof that must be presented alongside the signed challenge, not instead of it. The signed MFA certificate — produced by the Shibboleth/Duo login — is bundled with the challenge response and verified independently at the tiCrypt gateway. Critically, the email identity in the primary login and the email signed by the MFA provider must be an exact match. A single character difference results in a denied session, closing the door on subtle identity-substitution attacks.
Because the private key is the root of trust, tiCrypt stores no passwords — hashed or otherwise. The server freely shares users' public keys, just as SSL/TLS does, because there is nothing sensitive to expose. A full database breach via SQL injection would yield an attacker nothing actionable. The key cannot be reconstructed from anything the server holds alone.
What This Means for Your Institution
| Traditional MFA Integration | tiCrypt's Approach |
|---|---|
| MFA baked into the backend | MFA treated as an external proof-provider |
| Compromise of auth = compromise of data | Compromise of auth server ≠ access to data |
| Session tokens can be intercepted or reused | Digital signatures and timestamps prevent replay attacks |
| One layer of trust | Multiple independent cryptographic layers |
The database itself tells the same story: tiCrypt stores no hashed passwords. The server freely shares users' public keys — just as SSL/TLS does — because there is nothing sensitive to expose. A full database breach via SQL injection would yield an attacker nothing actionable.
Security That Earns Its Confidence
MFA is a powerful tool, but tools are only as good as the architecture around them. By refusing to grant MFA unconditional trust — and instead using cryptographic verification, split credentials, and strict identity matching — tiCrypt ensures that your institution's most sensitive research data stays protected even when individual components are tested.
In a true Zero Trust environment, nothing gets a free pass. Not even the second factor.
Want to learn more about tiCrypt's security architecture? Read our Security White Paper →